📌 Summary

While working on hashicorp/vault#30555 I discovered a strange "bug" in the Hds::Form::Label: essentially in the case of a radio group (an Hds::Form::Field) where the possible values are booleans true/false and the values are used also as ID for the elements, the for HTML attribute behaves differently than the id HTML attribute:

• for={{true}} in the template → renders as for attribute, without value
• for={{false}} in the template → it does not render the for attribute
• id={{true}} in the template → renders as id="true" attribute
• id={{false}} in the template → renders as id="false" attribute

This means that, while for the false case the association between the id of the input and the for of the label is maintained, because the ID is generated as guidFor() by the getElementId() function, in the true case this association is broken, because the getElementId() function sees that an ID is provided (element.args.id evaluates to true), and so it passes this argument to the id of the input, which is converted to a string, and passed to the for of the label, which is not converted to a string but simply omitted.

To fix this discrepancy, I have just wrapped in double quotes the for assignment in the handlebars template of the Form::Label component.

🛠️ Detailed description

In this PR I have:

• forced for attribute in Hds::Form::Label to be a string
• added special use case for Hds::Form::Radio::Group with boolean values to showcase
• added integration test for
  • Hds::Form::Label for use case when @controlId is a boolean
  • Hds::Form::Radio::Group for use case when RadioField @id is a boolean

👀 Component checklist

• Percy was checked for any visual regression
• A changelog entry was added via Changesets if needed (see templates here)

💬 Please consider using conventional comments when reviewing this PR.